Nexus samples: use business IDs for workflow IDs#297
Nexus samples: use business IDs for workflow IDs#297VegetarianOrc wants to merge 1 commit intomainfrom
Conversation
Stop using the Nexus request ID (nexus_cancel) or bare uuid4 (hello_nexus, nexus_multiple_args) as the backing workflow ID. Build a meaningful business ID from the operation input and append a uuid4 suffix for uniqueness. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
chrsmith
left a comment
chrsmith
left a comment
There was a problem hiding this comment.
As far as I know this is all on the up and up. But do we still want to include a UUID in the "Workflow ID"? Since it isn't required for uniqueness (that's the "Run ID", right?) wouldn't this just lead to Workflow ID spam?
e.g. you'd want the Workflow ID to be something like "reticulate-splines_job-xxx" (so the workflow ID would be unique per-job, but not necessarily need its own UUID)?
I assume this is the "right way", mostly asking for my own understanding.
The workflow ID is the main tool used to identify a workflow after it's been started. The Run ID is useful for differentiating workflow runs that happen in various scenarios like a workflow that was continued-as-new. You're right that the workflow ID doesn't necessarily need its own UUID and could use some sequential job number or the like to use unique jobs. In many scenarios the differentiator in a workflow ID winds up being a UUID because the underlying business concept is also identified by a UUID (i.e. user id, order id, etc). |
3 participants
What was changed
Stop using the Nexus request ID (nexus_cancel) or bare uuid4 (hello_nexus, nexus_multiple_args) as the backing workflow ID. Build a meaningful business ID from the operation input and append a uuid4 suffix for uniqueness.
Why?
Our samples should reflect best practices around creating meaningful IDs. Part of temporalio/features#692.